Every object, for example units, categories and documents, in Content Studio are protected by Security descriptors and Access Control lists (ACL). There is one Security descriptor on each object and each Security descriptor has an owner and an ACL. The ACL consists of a carefully ordered list of trustee (users or groups) identifiers and an access mask that describes what the caller can or cannot do with the object.

Every call Content Studio makes to its underlying database is checked against the ACL on the affected object making it possible to control access to every object in the system. The access checking logic is implemented on a low level, close to the data, and just like the operating system it uses a pessimistic approach to access control.

When access checking is performed, Content Studio notifies the internal access checking mechanism its intentions, the identity of the user and the object to access. The rule specifies that every user is denied access unless a GRANT-entry that matches one of the groups in the caller's mapped groups or the caller self is found. If a matching DENY-entry is found the caller is denied access unless the user also is the owner of the object. For the owner, access READ and WRITE SECURITY is always guaranteed.

A sample ACL on a fictive document (web page) might look like:

  • Allow Everyone - Browse
  • Allow Editors - Read/Write/Create
  • Allow Jim Olsen - Publish
  • Allow Administrators - Full Control

This list will give everyone the right to browse the page on the web and all members of the Editors group the permission to edit the page. However, Editors cannot publish a new version of the page on the Internet since they are not given the permission to Publish. Instead Editors must notify a member in the Administrators group or Jim Olsen and ask one of them to publish the document.

This model is exactly the same as being used by Windows itself and enables a very fine grained access control model. As a last resort there are also DENY entries that take precedence over ALLOW entries, making it possible for administrators to explicitly stop access to any trustee on the object.

The permissions that are applicable can be separated into three main groups:
Permission valid on every object
Name Description
WriteSecurity Can change the permissions of the affected object. Also, certain other actions can require this permission. This permission is commonly referred as Admin.
TakeOwnership Can take ownership of an object. This permission is implicitly given to users that have the GlobalRights.GlobalGroupAdmin right. The owner of an object has exclusive Read-WriteSecurity permission on the object and cannot be locked out of that object.
Read Read access to the object. For container objects this permission regulates the right to list their contents, not the right to read the properties of the container itself.
Delete Can delete child leaf objects but not child container objects. For container this permission is for inheritance only and for leaf object the permission goes for the object itself.
Write Write access to the object. For container this permission is for inheritance only.

Permission valid on container objects only
Name Description
Create Can create new child leaf objects but not child containers.
CreateContainer Can create child container objects. Only meaningful for container objects.
WriteContainer Can write data for a container object.  Only meaningful for container objects.
ReadContainer Can read data for a container object. Only meaningful for container objects.
DeleteContainer Can delete a container object. Only meaningful for container objects.

Permission valid on objects in the document system (i.e. site, units, categories and documents)
Name Description
Browse The caller can browse the object (document). Applicable on file system folder objects for inheritance (root, unit or category) and direct on documents.
Approve Can publish a document. Only meaningful within the document system. For container this permission is for inheritance only and for leaf object the permission goes for the object itself.
SendForRevision Can start a workflow on a document. Only meaningful within the document system. For container this permission is for inheritance only and for leaf object the permission goes for the object itself.
RemoveFromRevision Can terminate a workflow on a document. Only meaningful within the document system. Workflow server uses this permission when it determines whether a user can terminate a workflow or not. For container this permission is for inheritance only and for leaf object the permission goes for the object itself.
Reject Can reject a document that is sent for revision. Only meaningful within the document system. Workflow server does not use this permission. For container this permission is for inheritance only and for leaf object the permission goes for the object itself.

ACL inheritance

Content Studio uses more or less the same ACL inheritance model as the operating system itself. In Content Studio, most of all objects are part of a hierarchal tree of parent-child objects and the idea with ACL inheritance is that entries marked for inheritance will propagate down to each of the objects children and further down in the tree.

Like the operating system, it is possible to stop the inheritance flow on any point in the hierarchy and every entry can be marked as being inheritable and whether or not containers and documents should inherit the specific entry.

Integration with the file system

Content Studio also replicates permission for file system objects (i.e. root, units, categories and documents) with their respective file representation. Since the calling user only reads from the file system (all other access is managed by the Content Studio service) only the Read/Execute permission is relevant to the calling user.

The only time a visitor accesses the file system (via http:// that is) is when she browses the Web site. The permission to browse is regulated by the permission BROWSE and this permission is translated to Read/Execute in the file system. This integration is done transparently in the background when a relevant permission is changed or when the file system is synchronized.

Custom Authentication Providers creates SID values that are unknown to the operating system. If they are well-written and use a custom authority value in their SID, Content Studio ignores these values when the file system permissions are written.

The security editor

In the Content Studio administrative interface you can edit most objects using the familiar security editor. The editor has three dialogs and the most used one is the standard dialog which is very similar to the dialog found in the operating system. With this dialog an administrator can perform most of the access control related tasks. In the standard dialog some of the permissions listed above is grouped together in order to make it simple for the administrator to manage the permissions.

Standard permission dialog
The standard permission dialog

Occasionally, the standard dialog does not provide the functionality one desires. This might be true when an administrator needs to stop the inheritance flow at a certain point in the structure and when there is need to add a non standard entry - for example an entry that only containers should inherit.

Advanced permission dialog
The advanced permission dialog

In order to add or edit a specific entry or a non standard entry you will use the ACL-editor dialog. This dialog displays very detailed information about a single entry and provides access to any inheritance rule and to all permissions defined on the object.

The ACL editor
The ACL editor dialog

Meta-data security

Security on meta-data is an advanced feature on the access control system that only works with EPT documents and allows very detailed control over components within a document. This is described in the chapter Meta Data Security.

Global rights

In addition to the permissions defined on particular Content Studio objects, Content Studio also supports global permissions or rights. These rights control tasks in the system that cannot be applied to any particular object such as the right to use the administrative interface. These rights are applied per security group only and are accumulative so that all your group memberships are taken into consideration. For example: in order to be able to use the administrative interface, at least one of the groups where a particular user is a member must have this right set. An administrator can edit these global rights on the property dialog for a registered group in Content Studio.

Group properties dialog
The group properties dialog

These group rights are very similar to the User Right Assignments policies found in the operating system.

Content Studio global rights
Right Programmatic name Description
Right to use advanced editing AdvancedEdit Used by the Content Studio application interface when displaying the visual document editor. If this right is set the user can see advanced editing features like displaying source code directly
Right to pass over approval BypassRevision Can bypass revision and publish direct in the Content Studio interface. This bit is valid only when revision support is enabled.
Full control over own objects ControlOwnObjects User can fully control any securable object she owns. A user needs the ControlOwnObjects right in order to be able to change permissions on a securable object when the user is the owner but does not explicitly has permission to change the object's permission settings. Users that holds the GlobalGroupAdmin right have this right implicitly.
Can delete from the recycle bin DestroyDocuments The user can delete document from the recycling bin regardless of her permissions. Normally the caller must have admin permissions on the document but this flag bypasses this.
Right to fully administer users and groups GlobalGroupAdmin User can admin all groups and rights. Callers that have this right are effectively administrators in Content Studio.
Can only use simple mode in Content Studio LimitedUserInterface If set the user can only use the simple user interface. Users holding the GlobalGroupAdmin flag are excluded from this constraint.
Right to use Content Studio Logon User can log on to the Content Studio web interface.
Can restart the Web site RestartWebSite The user can restart the web site.
Can run as background service ServiceQueueAdmin The caller can manage the service queues. Used by the CS Service Manager background process only.
Can synchronize documents and folders Synchronize The user can synchronize document but not kill all the site files. Normally the caller must have GlobalGroupAdmin rights but this flag bypasses this.
Can write program code WriteActiveContent The user can save document with executable content. Also needed for components and categories for components.